Suggest changes to SE skills section #231
Conversation
Here is my long-promised suggestion for changes to the section on SE skills. Some words on the motivation behind these changes: * First suggestion is to rename "software engineering skills" to "technical skills". This is in particular motivate by the fact that things like re-use and teamwork that are included in the research and communication skills are also usually regarded SE skills. I think it makes sense to focus here on the technical aspects in contrast. Also, it makes it a bit easier to motivate why RSE is different from "standard" SE. * Then I would suggest to mention the life cycle as first item in the list, as at least DOCBB and LIBS build upon that. I enriched the SWLC with a number of standard technical terms from SE, to show that all these things also have their place in RSE (albeit often in different forms). * MOD seems to be the skill to me that in SE is commonly called "program comprehension" so I added that term. So far for this PR. I have some more comments on the paper, but they will go another route.
|
That makes a lot of sense. |
|
Overall, the changes make a lot of sense. Thank you! I am however unhappy with the new name of 'technical skills' since some of the R and comm skills to some part are technical, (PM) without technical tools seems like a glass half full and (DOMREP) as well as 'Software publication' are also partially technical. Maybe it has to be some combination like 'technical software skills' or something along those lines. |
I see the term technical skills in the context of the other two pillars, research and communication skills. They are all neutral and snappy terms. I think taking those three pillars together it is clear that technical skills are the base software engineering skills. The research skills are the add-ons that make RSEs somewhat different. Both SE and researchers need to have communication skills. They all contain aspects of each other. I take PM tools as productivity tools, ie like a spreadsheet program (I know some people use them for data management...). In the same vein I have no clue how to operate the new fangled teams conference hardware.... We do have both SWREPOS and DOMREP. My understanding is that SWREPOS cover the technical details of using repos and version control. While DOMREP is about knowing your way around of specific repos that are relevant to a particular field. |
Co-authored-by: mschwarzmeier <[email protected]>
competencies.md
Outdated
| @@ -356,7 +356,7 @@ The role of an RSE lies somewhere on the spectrum between that of a researcher | |||
| (the "R") and a software engineer (the "SE") and, therefore, requires | |||
| competencies in both fields. RSEs typically apply their knowledge and | |||
| experience in larger teams which allows them to cultivate this hybrid nature. | |||
| Therefore, we categorise the competencies into three categories: *software engineering skills*, | |||
| Therefore, we categorise the competencies into three categories: *technical skills*, | |||
There was a problem hiding this comment.
I get why you want to change it, but, it's a nice touch that we pick up the (S) part of the RSE again, for the three pillars. I think we need to think a bit harder, to find a good compromise. Software craftmanship has already been taken at the end of the paper.
There was a problem hiding this comment.
I thought about this again, but next to "research skills" and "communication skills" I still think "technical skills" is the most appropriate among the suggestions circulated thus far. "Communication" also does not pick up anything from RSE, so that is not the pattern here.
There was a problem hiding this comment.
I agree with @annalenalamprecht here. I've recently talked about some of the major differences between SE and RSE, and things like navigating software citation and publication have a strong technical component, but not a software engineering component. (In other contexts one could frame them as being the skills that set RSE apart from SE, but calling them "research software engineering skills" would drop us deep into infinite recursion.)
There was a problem hiding this comment.
The more I think about it the more I agree with technical skills. So fine by me.
competencies.md
Outdated
|
|
||
| <!-- Use repositories --> | ||
| \skillsection{SWREPOS} | ||
|
|
||
| The RSE should be able to identify and use fitting public platforms (so-called software repositories or repos) to share the artefacts they have | ||
| created and invite the public to scrutinise them for public review. | ||
| The RSE should be able to identify and use fitting public platforms (so-called software repositories or repos with version control) |
There was a problem hiding this comment.
I feel that the big competencies over here should be tech stack independent, and therefore we concentrated on the sharing with people and reviewing of contributions aspect of platforms like github. Due to them being manifestations of human interactions I feel they should exist even after the point in time, when the version control aspect is not visible to the average user anymore but suitably automated away. Side note: we need to introduce the word repo here, since we use it later on the tables which are less abstract.
There was a problem hiding this comment.
not mentioning version control here is fine with me
There was a problem hiding this comment.
As far as I can see in current main, "version control" as a skill is only mentioned in passing in Appendix A. This is widely at odds with current teaching practice, where VCS is one of the early and central (perhaps the central) skill taught to researchers (see, e.g., The Carpentries curricula, but also Helmholtz & DLR practice).
I see the point you are making @CaptainSifff, but think it'd be very odd not to mention version control here at all!
In fact, I think that the current wording is a bit too abstract to explain the use of SWREPOS in the tables further down, where, e.g., Table 1 says "Should seamlessly interact with the repository of their project.", where repository to me clearly points to a version control repo! I'll make a change suggestion to that effect.
There was a problem hiding this comment.
And even thinking of the future of automation. I'd still want some form of versioning to be able
to point to the specific version I used to do my computations.
So I'd still have to somehow interact with it.
There was a problem hiding this comment.
Oh and who would be most likely to automate the version control aspect of research?
Us RSEs probably xD So we should still know how it works to be able to maintain the software.
There was a problem hiding this comment.
I wonder if the issue is that there is a difference between versioning and version control. The repo tracks changes, in the simplest case that is just a linear history of changes (which is sufficient for a small project). Versioning then identifies particular snapshots of the software. Different strategies for versioning exist - major.minor.micro versions, pre-releases, development releases, time based releases, etc. Actually the right term is release management. I think that is something that is missing in the paper.
competencies.md
Outdated
| - Digital ecosystem module: Programming languages are not enough to work in a digital ecosystem, hence we require something like software craftsmanship, where tools such as the Unix shell, version control systems, build systems, documentation generators, package distribution platforms, and software discovery systems are taught to strengthen skills in (\gls{LIBS}, \gls{DOCBB}, \gls{SWREPOS}, \gls{SRU}). | ||
| - Software architecture module: Here we teach software design and \ac{SE}, again strengthening (\gls{DOCBB}, \gls{LIBS}) on a more abstract level. | ||
| - Software engineering module: Here we develop foundational software engineering competencies (basic knowledge and skill regarding requirements engineering, software architecture and design, implementation, quality assurance, software evolution), practicalities of carrying out a software project (e.g., use of version control and other software development support tools), again emphasizing and strengthening (\gls{DOCBB}, \gls{LIBS}) on a more abstract level. |
There was a problem hiding this comment.
The meaning has changed here.... The Software Development tools, we would have placed into Digital Ecosystem Module, whereas the architecture part over here, is more like the high-level view of how to grow big softwares.
There was a problem hiding this comment.
I guess we can remove the "practicalities ..." part here, especially as the importance of practical projects is emphasized a little later in the paper.
| with \gls{software-publication}. The RSE should be aware of this life-cycle | ||
| and be able to predict and cater to the changing needs of a software project as it moves through the stages. |
There was a problem hiding this comment.
I don't see, how to predict changing needs beyond the most obvious ones.
There was a problem hiding this comment.
@mschwarzmeier What exactly is your question/point here?
There was a problem hiding this comment.
I am not sure, I fully understand this sentence. Maybe an example could help?
@annalenalamprecht
There was a problem hiding this comment.
This has just been moved from a different position in the paper is not really a new addition.
So let's just keep it as is for now.
There was a problem hiding this comment.
Reminder to Flo: I think currently it's duplicated.
|
We decided to postpone this discussion to next friday 23.02. Or whichever day the poll suggests... |
|
Use Software Skills as heading for the SE skills. |
…n it.... Co-authored-by: Stephan Druskat <[email protected]>
Same here, get the code in the MR to suggest on it. Co-authored-by: Stephan Druskat <[email protected]>
We should sharpen the notion of repos anyway. I think we continue the discussion in the-teachingRSE-project#241
|
So, I think I have created in here a new state for discussion. On the ToDo List are:
After fixing these minor things(Or I do it in main) I could merge this MR and we can continue on the new issues. What do you think @annalenalamprecht , @sdruskat , @jpthiele , @mhagdorn |
|
this looks good to me. I do like the change to Software/Technical Skills. Update: I found another instance of software engineering skills and updated it accordingly |
|
In the RSE tasks and responsibilities section we have under the "Proper development" bullet point SE skills. Do we want to change the abbreviation? We do have it in the glossary. I think it is fine since we are talking about actual software engineering tasks. But I did make we wonder given we went to great lengths to define technical skills. |
Here is my long-promised suggestion for changes to the section on SE skills. Some words on the motivation behind these changes:
So far for this PR. I have some more comments on the paper, but they will go another route.